With rapid development of computer networking technologies and mobile communication computations, there are increasingly higher requirements for the mobility provided by the network. Request for Comments (RFC) 3775 proposes a solution to addressing mobility at the network layer: Mobile Internet Protocol version 6 (IPv6).
Referring to FIG. 1, the configuration of the existing Mobile IPv6 is shown. There are three basic network entities in the Mobile IPv6.
A Mobile Node (MN) is a node which may save an ongoing communication while moving from one link to another link on the network. A communication may be performed with a node as long as the home address of the node is known.
A Correspondent Node (CN) is a peer node communicating with the mobile node, and may be mobile or fixed.
A Home Agent (HA) is a router on the home link, and maintains information such as the current position of an MN which has left its home. The router has a port connected with the home link of the MN. When the MN moves to a foreign link, the HA intercepts the information packets directed to the home address of the MN, and then forwards the packets to the MN through a tunnel mechanism. Also, the HA processes and maintains the current position information of the MN.
A Home Address (HoA) in FIG. 1 is a globally unicast routable address assigned to the MN. The corresponding MN may be accessed always through this address. The Care-of Address (CoA) is a related IP address obtained when the MN moves to a foreign link. An MN may have several care-of addresses at a time.
Referring to FIG. 2, data transfer process for the mobile IPv6 in the conventional art is shown.
As provided in the mobile IPv6 specification, when an MN moves from one link to another, the ongoing communication through the home address is not interrupted. The mobility of a node is transparent to the transport layer and other higher-layer protocols. An MN may be uniquely identified by its home address. When the MN roams to a foreign network, a care-of address may be generated in a certain manner, and is reported to the home agent in a binding update message. When the CN transmits a packet to the MN, the HA may intercept the packet directed to the MN, and forward the packet to the MN in a tunnel mode. When the MN transmits a packet to the CN, the packet is transmitted to the HA in a tunnel mode, and the HA then may de-capsulate the tunnel packet and forward it to the CN.
The above communication forwarded by the HA between the MN and the CN may be referred to as a triangle route mode. In this mode, transmission delay may be caused and the overhead in the header of a communication packet with the MN is substantial. The burden on the home link of the MN is increased, and the route is not optimized.
To solve the above problems, the Mobile IPv6 specification provides a route optimization mode in which a direct communication may be performed between the MN and the CN supporting the Mobile IPv6. To perform a direct communication between the MN and the CN, a communication registration process is performed first between the MN and the CN to accomplish binding update, so that the CN and the HA save information about binding in a binding buffer and the MN saves information about the CN in a binding update list. During the binding update process, the MN sends its address binding information to the CN in a Binding Update (BU) message. To prevent the communication between the MN and the CN from being attacked, it is desirable to protect the BU message.
In the route optimization mode, a Return Routability Procedure (RRP) is introduced into the Mobile IPv6 and may be used to generate a binding management key. The binding management key is used to protect the binding update and binding acknowledgement messages between the MN and the CN.
Referring to FIG. 3, an existing RRP is shown.
When attempting to communicate with the CN in the route optimization mode, the MN transmits a home test initiation (HoTI) message and a care-of test initiation (CoTI) message to the CN (for example, steps 301a and 301b in FIG. 3. There is no strict requirement for the sequence of steps 301a and 301b).
The HoTI message is used to inform the CN of the home address and the Home Init Cookie of the MN, so as to request the CN to provide a home key generation token; the CoTI message is used to inform the CN of the care-of address and the care-of Init Cookie of the MN, so as to request the CN to provide a care-of key generation token.
The HoTI message reaches the CN through the relay of the HA; the CoTI message is transmitted to the CN directly.
The CN generates a home key generation token and a care-of key generation token, which are transmitted to the MN through the returned home test (HoT) message and care-of test (CoT) message respectively (for example, steps 302a and 302b in FIG. 3. There is no strict requirement for the sequence of the two steps).
Upon receipt of the HoTI message, the CN calculates the home key generation token as follows:Home Keygen Token=First(64, HMAC−SHA1(Kcn, HoA|Nonce|0)).
Upon receipt of the CoTI message, the CN calculates the care-of key generation token as follows:Care-of Keygen Token=First(64, HMAC−SHA1(Kcn, CoA|Nonce|1)).
In the above equations, Kcn is a key of the CN, and Nonce is a random number generated by the CN.
Then, the CN returns an HoT message carrying the home key generation token, which is relayed by the HA to the MN. The CN also returns a CoT message carrying the care-of key generation token, which is transmitted to the care-of address of the MN directly.
After the MN receives the HoT message and the CoT message, the RRP flow comes to an end. Hereafter, the MN performs a care-of binding update process, including the following steps.
The MN transmits a BU message carrying the binding update information.
Upon receipt of the HoT message and the CoT message, the MN performs a Cookies check. After the check is passed, the home key generation token and the care-of key generation token are extracted, and are used to calculate the binding management key (Kbm) as follows:Kbm=SHA1(Home Keygen Token|Care-of Keygen Token).
The MN generates a Message Authentication Code (MAC) for the BU message with Kbm, as the authentication data of the BU message, which is shown in steps 303a and 303b of FIG. 3.
The CN returns a binding acknowledgement (BA) message carrying the binding update acknowledgement information (as in step 304 of FIG. 3).
After verifying the BU message, the CN adds an entry for the MN in its binding buffer, generates the MAC in the BA (Binding Acknowledgement) message as the MN, and transmits the message to the MN.
After receiving the BA message and verification is passed, the MN adds an entry for the CN in its binding update list.
When the MN de-registers the binding relationship with the CN, Kbm=SHA1(home key generation token) is used to generate the MAC in the BU message.
In implementation of the present invention, the inventor has found several problems existing in the conventional art.
It can be seen from the above binding update process that the binding management key between the MN and the CN is secure when assuming that the CoT and HoT messages cannot be intercepted simultaneously by an attacker over the links between the HA and the CN and between the MN and the CN. But in fact, an attacker may intercept the CoT and HoT messages by choosing an appropriate position. Moreover, the CoT and HoT messages may be easily obtained if nodes on the two different links cooperate. After obtaining the CoT and HoT messages, the attacker may calculate Kbm, and naturally the BU message may be forged.
Additionally, a malicious node may choose an appropriate position, for example, on a link between the HA and the CN, transmit CoTI and HoTI messages to the CN by imitating the MN via RRP. Due to lack of necessary identity authentication information, the CN cannot identify whether a message is transmitted from a counterfeit MN, and thus cannot generate a suitable binding entry. In particular, when a BU is sent for cancellation of the binding relationship, if a hostile node intercepts the HoT message, it may generate the MAC in the BU message with Kbm=SHA1(home key generation token). Upon receipt of the BU message, the CN may verify the BU with Kbm=SHA1(home key generation token). After the verification is passed, the corresponding binding entry is cancelled. In this way, information exchange between the MN and the CN can only be relayed through the HA, and overloading may be caused on the home network.
In a summary, the method for generating Kbm through RRP has a very limited security.